IBIS Macromodel Task Group Meeting date: 11 July 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad: Walter has an EMD proposal to discuss. - Ambrish: BIRD 190 should not appear under tabled topics. It was untabled at the last meeting. - Radek: The BIRD 158 agenda item (#8) is obsolete. I produced a new version, and we discussed it last meeting. - Arpad: I sent a private email to Radek because I have detailed feedback on the updated version of BIRD 158. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: EMD BIRD draft introduction: - Walter: BIRD draft emailed to ATM June 28. - EMD is basically EBD using IBIS ISS subcircuits. - Largely copy-and-paste from EBD section of IBIS and from BIRD 189. - I think it's relatively straight forward, but needs thorough review. - I think it's close to being finished, but I don't think it is for IBIS 7.0, so there's no need to rush. - There are a couple of issues that we need to think about: - EBD only has one connector. Here there's a possibility of allowing multiple connectors. I think people objected to multiple connectors for EBD because it might step on EDA tools' turf. I've written EMD for a single connector. - How do we refer to the pins in the EMD [Pin List] itself. For the pins on IBIS [Component]s we use the reference designator (e.g., u1.7), but how do we do that for the EMD Pins? Perhaps .7, or j.7 (adopt j as the reference designator for the EMD), or this.7? - Rail terminals? - We can use reference designators just like signal pins (e.g. u1.8). - We will also want to use signal_name like GND. - All pins on the module with that signal_name could be shorted. - Or say all pins on a specific [Component] or in the [Pin List] with that signal_name are shorted together. There are no bus labels in EMD so we don't have that to consider. - Ken: Do we still have fork, end fork, etc. describing the paths as in EBD? - Walter: No the ISS subcircuit instance replaces the path descriptions. - Bob R.: I suggest we introduce this at the Interconnect meeting before uploading it. There might even be more changes in 189. - Walter: I'm fine with that. I think we can hold off until 189 is approved. - I think this is 98% done, but the last 2% will take time. - Arpad: When you refer to "only one connector," are you saying traditional EBD has a connector and then paths that dead-end at the chips, and that you would like to have a through-type arrangement going from one connector to another, as if between the pin and the pad? - Walter: That's certainly an option we could adopt. I think this was brought up the last time, and people objected to having multiple connectors. They thought that would compete with EDA tools. I think we will likely keep it to one connector with a single [Pin List]. - Arpad: One thing we might want to address here is the deliberate deficiency we built into BIRD 189, where we disallowed the one-to-many and many-to-one mappings for signals. - Walter: That's not an issue here. That issue was inside the package. Here you can have one pin go to multiple [Component]s or go to multiple pins on a single [Component]. - Bob R.: In BIRD 189 we only have a one-to-one restriction for I/O pins. - One-to-many and many-to-one exists for rails. - Walter: Here in EMD, since we've eliminated the paths, it's just a subcircuit with a bunch of terminals. Lots of the BIRD 189 complications just don't exist for EMD. BIRD 191: - Arpad: What is the reason that we have to do BIRD 191? - Up until now, we had "pin" or "die" (pad and buffer meant the same thing). - Now with BIRD 189 we separate the buffer from the die-pad. - But who is going to make SI simulations at the pad if the buffer terminal is separate? - If measurements at the buffer are more accurate or more important, do we still need the "pad" location? Do we need both? - Walter: Yes, compliance testing may be done at the pad. - Michael M: We need to be very clear and careful with terminology. - Meanings of terms have often changed since the original spec was written. - What's easiest for various probing? - Pin or ball is easiest. But with faster edge rates the package and on-die interconnect are increasingly important, and probing there is less useful. - If you have a die without a package, it's easy to probe "after" (Tx sense) the on-die interconnect, what we call the die pad. - I would argue the hardest thing to probe is the at the buffer. - Bob R.: If doing it by simulation you'd have access to that point. - But the purpose is not to defend the choice of locations. - The purpose of this is for completeness and consistency of terminology. - Remember that with an interconnect model you can now go directly from the buffer to the pin, and you no longer have access to the "pad" location in that case. - Michael M.: What do Vref, Rref, etc., mean? - Are they before or after the on-die interconnect, or at the pin? - We need to be clear. - Bob R.: That's why the Si_location is important. It gives the location where they are specified. - Ambrish/Arpad: This is also related to the A_to_D probing locations in [External Model]. - Arpad: In the current spec, for a receiver model you can put the A_to_D at the pad or at the core side of the receiver model. - With BIRD 189 interconnect modeling separating pad and buffer, we would probably also have to extend the A_to_D location to have a pad option, a core side option, and a buffer terminal option. - Arpad: This is why I'm concerned that we are opening a bigger can of worms. - From an SI perspective we are probably more interested in the buffer waveforms than the pad waveforms, now that they are separate. Wouldn't it be easier to just make the "die" location now mean the buffer terminal? Do we need to go from two choices to three? Instead of adding a third option, just change the meaning of "die" to the buffer terminal. - It seems like this will have a lot of ramifications. - Bob R.: It will be introduced at the next Open Forum meeting. - Something needs to be done because we use "die-pad" in BIRD 189. - If we went with something like Arpad's suggestion (to change the meaning of "die" for Si_location and Timing_location), we would then at least need a statement that buffer location and "die" location are considered the same even when using an interconnect model. BIRD 158.6: - Discussion: Arpad noted that he had a significant list of comments based on BIRD 158.6 draft 1. Bob R. noted that the term "pad" was used in the draft but not defined in any drawings or figures. He felt this should be clarified to ensure there was no confusion with Interconnect Model "pad" terminology. Arpad said he would send his comments to the ATM reflector so everyone could review them. Radek said editorial changes could be made before the next meeting, but since we had discussed technical issues at the last meeting he preferred not to make any technical changes unless they were discussed during a meeting first. BIRD161.2 Supporting Incomplete and Buffer-only [Component] Descriptions: - Michael M: If BIRD 191 is adopted, I believe BIRD 161 becomes less important and can be deferred until after 7.0. - First introduced in 2013. - Tried to do some of the same things Bob R. is doing in BIRD 191. - Address the fact that Timing_location and Si_location needed to be updated in light of the new Interconnect rules. - BIRD 161 contained some other interconnect related statements that BIRD 189 has now made obsolete. - This new draft removes everything that is addressed in BIRD 189. - It now focuses on adding two new Sub-Params to [Component]. - Scope - Allowed values "Complete" or "Partial" (default "Complete"). - Specifies whether the [Component] describes a complete manufactured device, or whether it's a partial description. - "Partial" [Component] might only define one [Pin] and use one [Model]. - Ideally every .ibs file would a have full [Pin] list for an entire component. This rarely happens, and it can be a pain at the beginning of development. IBIS rules prevent me from just giving someone a [Model], I'm forced to distribute a [Component]. - Scope Sub-Param allows the model maker to tell the recipient whether the [Component] is meant to define a real component or not. - This is a better approach than simply making it legal to not provide a [Component] keyword. - Pin_reference - Related to Scope. - Specifies whether [Pin] entries really mean pins, or just the buffer, or buffer and on-die interconnect. - Allowed values "Pin", "Die", "Buffer" (default "Pin"). - Pin_reference makes it easier to tell the user what is included. Many keywords ([Pin], [Diff Pin], etc.) by their very name imply Pin, which may not be correct for a "Partial" model. - At the very least, we need "Scope" in order to support incomplete (e.g., buffer-only) descriptions. - Bob R.: I think there's a lot of very complicated vetting for this. - [Pin], [Diff Pin], [Pin Mapping], etc., there could be a lot of effects. - I don't think we should consider it for 7.0. - This Scope might be useful purely as information for the user, but I might recommend EDA tools simply ignore it. - The term "Partial" vs. "Complete" (or incomplete) has other connotations. - Michael M: I agree with most of what you said, but let's not assume IBIS is only for those who sell complete packaged parts. - For example, an IP vendor may have a complete description of an IP buffer set, and that should be legal to distribute to a package vendor. - Bob R.: It is legal, you'd just put in a default zeroed out [Pkg], etc. - All you need to have a "complete" IBIS model is that every pin in the [Pin] list is associated with a model (including rails, NC, etc.). - As a practical requirement we said the model "shall" document all the pins. - We've reduced that to "should" or "recommend" it should. - Language used in this BIRD may not be consistent with Interconnect parlance. - Arpad: I reviewed it too. - I do see the areas that could be removed from it, and I see the new text. - We will need to review its verbiage very carefully, because after the removal of some of the old text the verbiage becomes inconsistent and/or confusing. - Michael M: Agreed. - Mike L.: Most of the models I see are buffer-only models. - There are many of them out in the world. - I do see some benefits from putting models in one category or another. - EDA tools might be able to deal with them differently or offer only the appropriate ones to the user. - I do see an issue with terminology. - There's a continuum. One file might only have one buffer and everything else is invented overhead. The other extreme would be a fully complete [Component] for an actual part. - What's desired here is a binary flag to indicate when you have "buffers only", but use of "Complete" or "Partial" implies something else. - Maybe we could change the allowed values to "buffers-only" vs. something else. - Bob R.: As an example of Mike's point, it's real to offer an ASIC library of various buffer models all packaged into one big [Pin] list, and the intent is just to provide buffer models. - Ken/Mike L. - FPGA models do that all the time. - Michael M: Motion to table BIRD 161. - Bob R.: Second. [no one opposed] BIRD 190: - Ambrish: I just wanted to revisit this quickly. - I'm hoping everyone will agree that it's only a warning for the time domain redriver flow. - Someone who comes across the repeater section may not look back to the warning in the single channel flow. - Let's keep the flows simple. - Arpad: Is this scheduled for a vote in the Open Forum? - Walter: It is eligibile, but not scheduled. - The repeater flow references doing things according to the normal single channel flow. That section already has the warning words Ambrish wants. - Passing this would reaffirm what I believe we know is an incorrect flow. - Arpad: Do we need more discussion here, or do we go to the Open Forum? - Ambrish: I would want to get consensus here in ATM before I would put it up for a vote in the Open Forum. - We haven't really specifically voted on this in the ATM strictly on the merits of this BIRD. We had a straw poll that may have been under the assumption that this affects the statistical flow too. - Walter: Let's have a discussion next week, and then we can make a recommendation to the Open Forum. - Ambrish: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. AR: Arpad to email his BIRD 158.6 draft 1 comments to the ATM reflector. ------------- Next meeting: 18 July 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives